-
Notifications
You must be signed in to change notification settings - Fork 71
Add generic policy handler; refactor IAMAuthPolicy, TargetGroupPolicy, VpcAssociationPolicy #547
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
I was thinking of getting rid of pointer definition and came up with this example, what do you think? |
4 tuple of types isnt that bad as it looks like, especially pointerType can be derived from structType and I dont need explicit type declaration. I dont think it worth replacing it with reflection. I end up with smaller helper constructor functions that simplifies usage outside of policy.go. As I mentioned before we still need to maintain mapping between single and plural crd structs. For example: func NewVpcAssociationPolicyHandler(log gwlog.Logger, c k8sclient.Client) *PolicyHandler[*VAP] {
phcfg PolicyHandlerConfig := PolicyHandlerConfig{
Log: log,
Client: c,
TargetRefKinds: NewGroupKindSet(objs...: &gwv1beta1.Gateway{}),
}
return NewPolicyHandler[VAP, VAPL](cfg: phcfg)
} |
xWink
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some small comments. Also would like to see unit tests on the new policy helper functions.
|
I feel like this PR kinda gives a vibe of a sophisticated TypeScript code doing type circuses. Doing a recap of why I thought this was hard to read:
If we manage to reduce it to just P and PL I think it is more consistent and readable (I mean, except for a few lines of reflection magic) And I'm okay with having both single and list types on handler generics. I think it has benefits, as you mentioned. |
|
@solmonk I agree it would be nicer to have only 2 types: policy and list. I dont mind to follow up after this pr, currently this behavior is isolated to local k8sClient struct and not exposed outside, it should be an easy change after. |
|
@xWink addressed minor comments, but not unit tests. I will do follow-up on this PR with unit tests, currently it's being manually tested and ran full e2e test suite. |
6fb49f0 to
d824146
Compare
|
LGTM. Thanks for putting this together! |
Note
Add generic policy handler and refactor IAMAuthPolicy, TargetGroupPolicy, VpcAssociationPolicy with use of generic handler.
Testing:
Generic Policy Handler
The high-level design is to introduce generic helper struct with collection of different methods to work with Policy CRD's. This helper/handler is supposed to be used in controllers that interact with Policy CRDs.
Controller's code should explicitly call different, and relatively small methods of handler, so that it should be easy to tell what controller does looking at controller's code.
Code includes some arcane golang around generics. For example:
These 4 generic types methods are results of having 2 types of policy structs Policy and PolicyList in every CRD. Also I need to make distinction between Policy and ref type *Policy for some functionality related to k8s client calls - Get and List.
All generic complexity stays in Policy file but interface is still simple with single type and I believe understandable methods.
PolicyHandler creation is as simple as it can be.
It's a not valid config to call all methods, but it's enough for compiler to understand it's IAMAuthPolicy and all related methods will be statically checked.
Partly address: #508
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.